[Buildroot] [git tag 2009.11] update for 2009.11

[Buildroot] [git tag 2009.11] update for 2009.11

[Peter Korsgaard]

commit: http://git.buildroot.net/buildroot/commit/?id=d0cb90792df5873af83f7277b17fe12aa1b91b19
branch: http://git.buildroot.net/buildroot/commit/?id=refs/tags/2009.11

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

this is a tag, so no patch shown

[Buildroot] [git tag 2009.11] update for 2009.11

[Michael S. Zick]

On Tue December 1 2009, Peter Korsgaard wrote:
> 
> commit: http://git.buildroot.net/buildroot/commit/?id=d0cb90792df5873af83f7277b17fe12aa1b91b19
> branch: http://git.buildroot.net/buildroot/commit/?id=refs/tags/2009.11
> 
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
> 
> this is a tag, so no patch shown
>

Would you please tag the repository with a 2010.02 branch tag?

That way users can continue to fix 2009.11 without being exposed
to the code-churn of producing 2010.02.

The "release and move-on" type of organization really is not appropriate
for something as mission critical as the build system in use.

Heck, after a decade, even kernel.org learned that lesson.  ;)

Mike
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 
> 

[Buildroot] [git tag 2009.11] update for 2009.11

[Peter Korsgaard]

>>>>> "Michael" == Michael S Zick <minimod@morethan.org> writes:

 Michael> Would you please tag the repository with a 2010.02 branch tag?

Sorry, I prefer to branch for bugfix releases instead (if needed) - So
that master is always where development is happening.

 Michael> That way users can continue to fix 2009.11 without being exposed
 Michael> to the code-churn of producing 2010.02.

Just create a local branch from the 2009.11 tag:

git checkout -b mybranch 2009.11

 Michael> The "release and move-on" type of organization really is not appropriate
 Michael> for something as mission critical as the build system in use.

 Michael> Heck, after a decade, even kernel.org learned that lesson.  ;)

No they didn't. Linus' tree doesn't have branches, and stable (bugfix)
releases are done from a completely different tree.

-- 
Bye, Peter Korsgaard

[Buildroot] [git tag 2009.11] update for 2009.11

[Michael S. Zick]

On Wed December 2 2009, Peter Korsgaard wrote:
> >>>>> "Michael" == Michael S Zick <minimod@morethan.org> writes:
> 
>  Michael> Would you please tag the repository with a 2010.02 branch tag?
> 
> Sorry, I prefer to branch for bugfix releases instead (if needed) - So
> that master is always where development is happening.
> 
>  Michael> That way users can continue to fix 2009.11 without being exposed
>  Michael> to the code-churn of producing 2010.02.
> 
> Just create a local branch from the 2009.11 tag:
> 
> git checkout -b mybranch 2009.11
> 

Which kills community collaboration by turning the tree into
number of users * number of local trees.

Keep development on "head" if you wish - its your organization;

But I would recommend against locking out the community or
splintering the community of users that want to see a working 2009.11.

Achieve that end anyway you like, anyway that does not feel as if
you are being insulted by the presumption that 2009.11 isn't perfectly
error free.
You are not being insulted, at least it was not my intent to insult.

Just acknowledge there are two goals to be served here:
The Buildroot maintainer's goal of an error free 2010.02 next year.
The Buildroot user's goal of an error free 2009.11 for use **now**.

Both can be archived if you don't splitter the support of 2009.11 
into individual, local, user trees.

Mike
>  Michael> The "release and move-on" type of organization really is not appropriate
>  Michael> for something as mission critical as the build system in use.
> 
>  Michael> Heck, after a decade, even kernel.org learned that lesson.  ;)
> 
> No they didn't. Linus' tree doesn't have branches, and stable (bugfix)
> releases are done from a completely different tree.
> 

[Buildroot] [git tag 2009.11] update for 2009.11

[Peter Korsgaard]

>>>>> "Michael" == Michael S Zick <minimod@morethan.org> writes:

Hi,

 >> git checkout -b mybranch 2009.11

 Michael> Which kills community collaboration by turning the tree into
 Michael> number of users * number of local trees.

 Michael> Keep development on "head" if you wish - its your organization;

There has been various requests for bugfix releases in the past, and I
have stated that I don't have any problems with that, but I don't have
free cycles over to look through fixes and verify what needs to be
backported. If someone wants to step up and point out what should get
backported (and preferably does the backport/test), then I don't have
any issues with doing bugfix releases now and then.

So far noone has stepped up to the task.

The only demand I have is that the bugfix releases are STRICTLY for
bugfix / security issues.

 Michael> But I would recommend against locking out the community or
 Michael> splintering the community of users that want to see a working 2009.11.

 Michael> Achieve that end anyway you like, anyway that does not feel as if
 Michael> you are being insulted by the presumption that 2009.11 isn't perfectly
 Michael> error free.
 Michael> You are not being insulted, at least it was not my intent to insult.

I'm certainly not insulted.

 Michael> Just acknowledge there are two goals to be served here:
 Michael> The Buildroot maintainer's goal of an error free 2010.02 next year.
 Michael> The Buildroot user's goal of an error free 2009.11 for use **now**.

 Michael> Both can be archived if you don't splitter the support of 2009.11 
 Michael> into individual, local, user trees.

No matter how you set it up it takes effort. I don't have the time to do
a good job doing it, and so far noone has stepped up to help me doing
it - Will you?

If the bugfix work is done in the master branch, another branch in the
same tree or in another tree is just a minor technical detail.

-- 
Bye, Peter Korsgaard

[Buildroot] [git tag 2009.11] update for 2009.11

[Michael S. Zick]

On Wed December 2 2009, Peter Korsgaard wrote:
> >>>>> "Michael" == Michael S Zick <minimod@morethan.org> writes:
> 
> Hi,
> 
>  >> git checkout -b mybranch 2009.11
> 
>  Michael> Which kills community collaboration by turning the tree into
>  Michael> number of users * number of local trees.
> 
>  Michael> Keep development on "head" if you wish - its your organization;
> 
> There has been various requests for bugfix releases in the past, and I
> have stated that I don't have any problems with that, but I don't have
> free cycles over to look through fixes and verify what needs to be
> backported. If someone wants to step up and point out what should get
> backported (and preferably does the backport/test), then I don't have
> any issues with doing bugfix releases now and then.
> 
> So far noone has stepped up to the task.
> 
> The only demand I have is that the bugfix releases are STRICTLY for
> bugfix / security issues.
> 
>  Michael> But I would recommend against locking out the community or
>  Michael> splintering the community of users that want to see a working 2009.11.
> 
>  Michael> Achieve that end anyway you like, anyway that does not feel as if
>  Michael> you are being insulted by the presumption that 2009.11 isn't perfectly
>  Michael> error free.
>  Michael> You are not being insulted, at least it was not my intent to insult.
> 
> I'm certainly not insulted.
> 
>  Michael> Just acknowledge there are two goals to be served here:
>  Michael> The Buildroot maintainer's goal of an error free 2010.02 next year.
>  Michael> The Buildroot user's goal of an error free 2009.11 for use **now**.
> 
>  Michael> Both can be archived if you don't splitter the support of 2009.11 
>  Michael> into individual, local, user trees.
> 
> No matter how you set it up it takes effort. I don't have the time to do
> a good job doing it, and so far noone has stepped up to help me doing
> it - Will you?
> 

I don't know enough GIT at the moment to make an intelligent answer to
the over all question.

But let us tackle one of the minor ones, and move forward towards the
"every release perfect" goal - this is, after all, a "mission critical"
system to its users.  ;)

Doing my best not to open up the question of "where" in the workflow the
bug tracking system belongs - lets take the easy way out, and leave it
just where it is; with a modification:

The system already has an "email to interested party" feature - -
Hard code it to make buildroot at busybox.net an "interested party" for
all entries made.

Using bug 729 as an example:

User opens new bug, to become bug 729...
On mailing list: [Bug 729] -Summary as subject-

Now the readers (users of Buildroot) reading the mailing list can
do "first level triage" on that report -

Responses appear properly threaded (if user pushes correct button) on
the mailing list -

If resolved on the mailing list, that bug can be (currently manually) closed.

Now picture the busy maintainer, running in circles to get a tagged release out...

The maintainer scans the thread, decides "no fix posted" and "no quick fix" -
(A.K.A: second level triage)

Tags the feature as "broke" in the menu config system with a reference to Bug:729
and moves gets on with doing something else.
The maintainer *might* update the status of the bug report;
The maintainer *might* update the mailing list thread;
but probably not, too time consuming at this point to do either.

But whatever the above sequence, it is now marked "broke" in the menu configuration
with a link to the bug report (and/or the mailing list archive thread).
Any user who finds something they want can now find a reference back
into the mailing list and/or bug tracker so they can contribute a solution.

Time and effort required at this point: minor, make buildroot at busybox.net an 
"interested party" to all bug tracker entries.
If easy to do, might even make that subject line tag: [tag:v2009.11, bug:729]

If this modification to the system had been in place two weeks ago -
2009.11 might not have shipped with an enabled, broken, sstrip.  ;)
All with *zero* additional time and effort on the maintainer's part.

Mike



> If the bugfix work is done in the master branch, another branch in the
> same tree or in another tree is just a minor technical detail.
>