Dreaming of a new bup release ...
100 views
Skip to first unread message
Alexander Barton
Aug 27, 2012, 1:15:24 PM8/27/12
to bup-...@googlegroups.com
Hello all!
The current project state makes me more and more wonder where bup is heading to – and probably someone can enlighten me a little bit ;-)
The state as it seems to be:
bup 0.25-rc1 has been tagged in GIT more than a year ago (June 9 2011), and since then, no more "releases" have happened. And the main (?) development branch, https://github.com/apenwarr/bup/commits/master, seems to be quite dead (as well as the other branches located there): no relevant commits since november last year, only a few minor fixes and side products of other projects.
Now I know that there are other branches, most notably the "tmp/pending/meta" and "tmp/pu/master" branches: it seems current development takes place there (see GitWeb here: http://anonscm.debian.org/gitweb/?p=users/rlb/bup.git).
So what is the maser plan?
Avery, do yo plan to merge "tmp/pending/meta" back to your master branch?
And what's holding this back?
Should I use some other branch for testing and using bup nowadays?
Rob, are you planing to to some sort of release on your own?
Concerning bup, I'm more or less an "end-user", mostly because of lacking Python skills. And as such, I think it would be really good to have more "official" releases, so people would have a better clue which codebase to use …
The "tmp" and "pending" verbs in the GIT branches don't build a lot of trust.
And what's the meaning of "pu", BTW?
"Release early, release often"!
Regards
Alex
The current project state makes me more and more wonder where bup is heading to – and probably someone can enlighten me a little bit ;-)
The state as it seems to be:
bup 0.25-rc1 has been tagged in GIT more than a year ago (June 9 2011), and since then, no more "releases" have happened. And the main (?) development branch, https://github.com/apenwarr/bup/commits/master, seems to be quite dead (as well as the other branches located there): no relevant commits since november last year, only a few minor fixes and side products of other projects.
Now I know that there are other branches, most notably the "tmp/pending/meta" and "tmp/pu/master" branches: it seems current development takes place there (see GitWeb here: http://anonscm.debian.org/gitweb/?p=users/rlb/bup.git).
So what is the maser plan?
Avery, do yo plan to merge "tmp/pending/meta" back to your master branch?
And what's holding this back?
Should I use some other branch for testing and using bup nowadays?
Rob, are you planing to to some sort of release on your own?
Concerning bup, I'm more or less an "end-user", mostly because of lacking Python skills. And as such, I think it would be really good to have more "official" releases, so people would have a better clue which codebase to use …
The "tmp" and "pending" verbs in the GIT branches don't build a lot of trust.
And what's the meaning of "pu", BTW?
"Release early, release often"!
Regards
Alex
Gabriel Filion
Aug 27, 2012, 8:05:37 PM8/27/12
to Alexander Barton, bup-...@googlegroups.com, Rob Browning
Hi there,
On 12-08-27 01:15 PM, Alexander Barton wrote:
> The current project state makes me more and more wonder where bup is heading to � and probably someone can enlighten me a little bit ;-)
> So what is the maser plan?
>
time to maintaining the project (no hard feelings, Avery, really), so
for now the tmp/pu/master and tmp/pending/meta branches are where the
project is living.
I'm also trying to give Rob a hand when I can so that he's not alone in
this.
> Should I use some other branch for testing and using bup nowadays?
branch from time to time, so it's non-trivial to follow. So if you
really want to be conservative, you'd better stick with 0.24b, or
0.25-rc1 for now.
since they're moving points at the moment, it's hard to recommend to
"end-users" to follow them. you'd have to be used to using git and
reviewing changesets yourself :\
we really do hope to be able to get that 0.25 release out as soon as
possible, though.
Once 0.25 is out, we hope to get rid of the current branch mess. We'll
probably have "master" and "next" or something similar.
> "Release early, release often"!
usually, that's good. but bup is currently near the point where an
important feature (saving file metadata) is going to be making its way
in and changing how we store and restore things. And since backups are
all about the accuracy of the stored and restored data, we _really_
don't want to mess this out by releasing too soon.
Rob, if you can complete my thoughts about the current state of the
metadata branch (trying to remember our discussions as accurately as
possible):
I think most of the code for saving and restoring metadata should be
there. Once all we're confident that everything is there, we'll ask for
people on the list to help out with as much testing as can be done.
after release 0.25 is out, we can probably get a bunch of releases out
faster with fixes and smaller feature additions to the interfaces.
--
Gabriel Filion
On 12-08-27 01:15 PM, Alexander Barton wrote:
> The current project state makes me more and more wonder where bup is heading to � and probably someone can enlighten me a little bit ;-)
> So what is the maser plan?
>
> Rob, are you planing to to some sort of release on your own?
Rob took over maintainership while Avery isn't able to dedicate enough
time to maintaining the project (no hard feelings, Avery, really), so
for now the tmp/pu/master and tmp/pending/meta branches are where the
project is living.
I'm also trying to give Rob a hand when I can so that he's not alone in
this.
> Should I use some other branch for testing and using bup nowadays?
> The "tmp" and "pending" verbs in the GIT branches don't build a lot of
trust.
I'd like to recommend using tmp/pu/master. However, we're rebasing that
trust.
branch from time to time, so it's non-trivial to follow. So if you
really want to be conservative, you'd better stick with 0.24b, or
0.25-rc1 for now.
since they're moving points at the moment, it's hard to recommend to
"end-users" to follow them. you'd have to be used to using git and
reviewing changesets yourself :\
we really do hope to be able to get that 0.25 release out as soon as
possible, though.
Once 0.25 is out, we hope to get rid of the current branch mess. We'll
probably have "master" and "next" or something similar.
> "Release early, release often"!
important feature (saving file metadata) is going to be making its way
in and changing how we store and restore things. And since backups are
all about the accuracy of the stored and restored data, we _really_
don't want to mess this out by releasing too soon.
Rob, if you can complete my thoughts about the current state of the
metadata branch (trying to remember our discussions as accurately as
possible):
I think most of the code for saving and restoring metadata should be
there. Once all we're confident that everything is there, we'll ask for
people on the list to help out with as much testing as can be done.
after release 0.25 is out, we can probably get a bunch of releases out
faster with fixes and smaller feature additions to the interfaces.
--
Gabriel Filion
Greg Troxel
Aug 27, 2012, 8:25:12 PM8/27/12
to Gabriel Filion, Alexander Barton, bup-...@googlegroups.com, Rob Browning
My $0.02: bup is way overdue for a release. Any time there is advice to
users to use git instead of the most recent release, that's a clue that
a release is seriously overdue. I understand what you mean about not
releasing a bad metadata version, but it seems like bup w/o the metadata
code should be released. That may be unwinding history and not having
merged any of the metadata support. Or it may mean powering through
finishing metadata soon.
Gabriel Filion
Aug 27, 2012, 8:38:54 PM8/27/12
to Greg Troxel, Alexander Barton, bup-...@googlegroups.com, Rob Browning
tmp/pu/master. that could be a release (maybe 0.25). that would give us
a stable point from which the metadata stuff would then be easier to
maintain/suggest for testing.
Rob, what do you think of the above? do we make that annoying "fixup"
branch an actual release?
--
Gabriel Filion
Niklas Hambüchen
Aug 27, 2012, 9:37:51 PM8/27/12
to Gabriel Filion, Greg Troxel, Alexander Barton, bup-...@googlegroups.com, Rob Browning
I think what Greg says makes sense.
Small fixes should go to the master branch, not on top of an
experimental feature branch that is hard to test by the public.
It should also be clear where the main repository for bup is.
Could you guys not just make a "bup" github group?
bup could then be reliably found at https://github.com/bup/bup,
and you could put some nice master/stable/metadata branches in, removing
all this confusion.
Small fixes should go to the master branch, not on top of an
experimental feature branch that is hard to test by the public.
It should also be clear where the main repository for bup is.
Could you guys not just make a "bup" github group?
bup could then be reliably found at https://github.com/bup/bup,
and you could put some nice master/stable/metadata branches in, removing
all this confusion.
Maaartin G
Aug 28, 2012, 4:07:05 AM8/28/12
to bup-...@googlegroups.com
On Monday, August 27, 2012 7:15:24 PM UTC+2, Alexander Barton wrote:
And what's the meaning of "pu", BTW?
Probably the same as here:
pu (proposed updates) is an integration branch for things that are not quite ready for inclusion yet (see "Integration Branches" below).
Alexander Barton
Aug 28, 2012, 6:53:09 AM8/28/12
to Maaartin G, bup-...@googlegroups.com
I'm using GIT myself, but wasn't aware of the "pu" abbreviation :-)
Regards
Alex
Rob Browning
Aug 28, 2012, 7:14:06 PM8/28/12
to Gabriel Filion, Greg Troxel, Alexander Barton, bup-...@googlegroups.com
Gabriel Filion <lel...@gmail.com> writes:
> hmm, perhaps you're right. we do have a good series of fixes in
> tmp/pu/master. that could be a release (maybe 0.25). that would give us
> a stable point from which the metadata stuff would then be easier to
> maintain/suggest for testing.
>
> Rob, what do you think of the above? do we make that annoying "fixup"
> branch an actual release?
So here was my plan:
> hmm, perhaps you're right. we do have a good series of fixes in
> tmp/pu/master. that could be a release (maybe 0.25). that would give us
> a stable point from which the metadata stuff would then be easier to
> maintain/suggest for testing.
>
> Rob, what do you think of the above? do we make that annoying "fixup"
> branch an actual release?
- Start running nightly metadata backups with t/compare-tree
verification or equivalent. (I got that going, and it's worked fine
so far, though I am excluding quite a bit from restore/verification
to speed up the process -- i.e. home, lib, usr, etc.)
- Discuss next steps on the list.
So here we are. As you suggest, I also think we should consider making
the contents of tmp/pu/master the new "main branch". Hopefully, we can
get more people to test, and once that settles out, we'll label the
result as 0.25.
Then, after I've run the automated backup/restore tests a little longer,
and after other people have run tests of their own, we can consider
adding tmp/pending/meta. I suppose it might make sense for me to post
the metadata patches to the list for review -- just like any other
proposed series. That would be fine, though there are a fair number of
patches. Thoughts?
With respect to our overall branching strategy, I'm open to suggestions.
It may make sense to just continue with the single master branch for now
-- once we get over this transition.
With respect to the repository, since I have a gitorious account, I
thought I might just move my work there.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Avery Pennarun
Aug 28, 2012, 7:50:19 PM8/28/12
to Rob Browning, Gabriel Filion, Greg Troxel, Alexander Barton, bup-...@googlegroups.com
On Tue, Aug 28, 2012 at 7:14 PM, Rob Browning <r...@defaultvalue.org> wrote:
> Gabriel Filion <lel...@gmail.com> writes:
>
>> hmm, perhaps you're right. we do have a good series of fixes in
>> tmp/pu/master. that could be a release (maybe 0.25). that would give us
>> a stable point from which the metadata stuff would then be easier to
>> maintain/suggest for testing.
>>
>> Rob, what do you think of the above? do we make that annoying "fixup"
>> branch an actual release?
>
> So here was my plan:
>
> - Start running nightly metadata backups with t/compare-tree
> verification or equivalent. (I got that going, and it's worked fine
> so far, though I am excluding quite a bit from restore/verification
> to speed up the process -- i.e. home, lib, usr, etc.)
>
> - Discuss next steps on the list.
This seems like a good plan to me, especially if other people also
> Gabriel Filion <lel...@gmail.com> writes:
>
>> hmm, perhaps you're right. we do have a good series of fixes in
>> tmp/pu/master. that could be a release (maybe 0.25). that would give us
>> a stable point from which the metadata stuff would then be easier to
>> maintain/suggest for testing.
>>
>> Rob, what do you think of the above? do we make that annoying "fixup"
>> branch an actual release?
>
> So here was my plan:
>
> - Start running nightly metadata backups with t/compare-tree
> verification or equivalent. (I got that going, and it's worked fine
> so far, though I am excluding quite a bit from restore/verification
> to speed up the process -- i.e. home, lib, usr, etc.)
>
> - Discuss next steps on the list.
start doing some similar tests of the metadata branch.
> So here we are. As you suggest, I also think we should consider making
> the contents of tmp/pu/master the new "main branch". Hopefully, we can
> get more people to test, and once that settles out, we'll label the
> result as 0.25.
fine. I don't mind merging it into my copy of the repo and tagging it
if that will help :)
> With respect to our overall branching strategy, I'm open to suggestions.
> It may make sense to just continue with the single master branch for now
> -- once we get over this transition.
> With respect to the repository, since I have a gitorious account, I
> thought I might just move my work there.
user friendly than github. But I guess it's a matter of preference.
We could try creating github.com/bup/bup as someone else suggested,
and share the rights around a bit. It's a little un-Linus-like (no
personal blame for a given archive) but oh well, if your single point
of failure is me, indications are you probably need to get yourself a
new one, or at least a multiple point of failure :)
Have fun,
Avery
Gabriel Filion
Aug 28, 2012, 8:15:06 PM8/28/12
to Rob Browning, Greg Troxel, Alexander Barton, bup-...@googlegroups.com
On 12-08-28 07:14 PM, Rob Browning wrote:
> [...]
> Then, after I've run the automated backup/restore tests a little longer,
> and after other people have run tests of their own, we can consider
> adding tmp/pending/meta. I suppose it might make sense for me to post
> the metadata patches to the list for review -- just like any other
> proposed series. That would be fine, though there are a fair number of
> patches. Thoughts?
on the git ml, there are series of 20 to 30 patches that do come in from
time to time. review is longer that way but it shouldn't be too
troublesome. and for feature additions or changes that require lots of
modifications everywhere, especially if those modifications tend to
disturb other features, it makes sense to send it all as a whole.
> With respect to our overall branching strategy, I'm open to suggestions.
> It may make sense to just continue with the single master branch for now
> -- once we get over this transition.
bup doesn't have a high volume of contributions, so it's probably ok to
maintain dev on the one branch and have "stable" code as tags. we can
change that mechanism in the future if it gets necessary.
> With respect to the repository, since I have a gitorious account, I
> thought I might just move my work there.
I'm not strongly opposed to using gitorious, but I don't particularly
like their web interface. It got better with time, but it's still way
too focused on developers. (I mean, if we push out code to a public
respository, the web interface exists mainly to make the code available
to users)
For me, using github and gitorious is the same wrt how "open" the
practice is. Gitorious' backend is open source v.s. github's that's
proprietary, and that's cool (although I don't know about anyone using
gitorious on their own servers since it's a pile of moving parts).
But in the end, we're pushing files to a 3rd party server that's
controlled by some 3rd party entity. But the code itself is free and
open source, and distributed among all contributors... so the
theoretical possibility of github "closing down" to serve only its
paying customers isn't too much of an issue (that wouldn't make them own
bup's code -- it would be the same as if gitorious' server was shutdown
because of lack of funding/interest)
All that story just to say that while I would be OK to go with
gitorious, I think github has some advantages wrt its web interface:
* easy to find/use zip and tarball download links
* the README is in your face when you find a project
* forked repositories are visually linked to the original one in the
interface, so it'd be easy to find the project account via Avery's
repository without him having to do anything about it.
* possibility of having a wiki if we ever need some more user-friendly
documentation (accessible with git, so clonable by anyone)
* possibility of hosting a website for bup (also clonable via git)
my 0.02$ ;)
--
Gabriel Filion
> [...]
> I also think we should consider making
> the contents of tmp/pu/master the new "main branch". Hopefully, we can
> get more people to test, and once that settles out, we'll label the
> result as 0.25.
sounds reasonable
> the contents of tmp/pu/master the new "main branch". Hopefully, we can
> get more people to test, and once that settles out, we'll label the
> result as 0.25.
> Then, after I've run the automated backup/restore tests a little longer,
> and after other people have run tests of their own, we can consider
> adding tmp/pending/meta. I suppose it might make sense for me to post
> the metadata patches to the list for review -- just like any other
> proposed series. That would be fine, though there are a fair number of
> patches. Thoughts?
time to time. review is longer that way but it shouldn't be too
troublesome. and for feature additions or changes that require lots of
modifications everywhere, especially if those modifications tend to
disturb other features, it makes sense to send it all as a whole.
> With respect to our overall branching strategy, I'm open to suggestions.
> It may make sense to just continue with the single master branch for now
> -- once we get over this transition.
maintain dev on the one branch and have "stable" code as tags. we can
change that mechanism in the future if it gets necessary.
> With respect to the repository, since I have a gitorious account, I
> thought I might just move my work there.
like their web interface. It got better with time, but it's still way
too focused on developers. (I mean, if we push out code to a public
respository, the web interface exists mainly to make the code available
to users)
For me, using github and gitorious is the same wrt how "open" the
practice is. Gitorious' backend is open source v.s. github's that's
proprietary, and that's cool (although I don't know about anyone using
gitorious on their own servers since it's a pile of moving parts).
But in the end, we're pushing files to a 3rd party server that's
controlled by some 3rd party entity. But the code itself is free and
open source, and distributed among all contributors... so the
theoretical possibility of github "closing down" to serve only its
paying customers isn't too much of an issue (that wouldn't make them own
bup's code -- it would be the same as if gitorious' server was shutdown
because of lack of funding/interest)
All that story just to say that while I would be OK to go with
gitorious, I think github has some advantages wrt its web interface:
* easy to find/use zip and tarball download links
* the README is in your face when you find a project
* forked repositories are visually linked to the original one in the
interface, so it'd be easy to find the project account via Avery's
repository without him having to do anything about it.
* possibility of having a wiki if we ever need some more user-friendly
documentation (accessible with git, so clonable by anyone)
* possibility of hosting a website for bup (also clonable via git)
my 0.02$ ;)
--
Gabriel Filion
rektide
Aug 30, 2012, 12:25:56 AM8/30/12
to Gabriel Filion, Alexander Barton, bup-...@googlegroups.com, Rob Browning
On Mon, Aug 27, 2012 at 08:05:37PM -0400, Gabriel Filion wrote:
> Hi there,
>
> On 12-08-27 01:15 PM, Alexander Barton wrote:
> > The current project state makes me more and more wonder where bup is heading to – and probably someone can enlighten me a little bit ;-)
> Hi there,
>
> On 12-08-27 01:15 PM, Alexander Barton wrote:
>
> > So what is the maser plan?
> >
> > Rob, are you planing to to some sort of release on your own?
>
> Rob took over maintainership while Avery isn't able to dedicate enough
> time to maintaining the project (no hard feelings, Avery, really), so
> for now the tmp/pu/master and tmp/pending/meta branches are where the
> project is living.
> I'm also trying to give Rob a hand when I can so that he's not alone in
> this.
I'm ok with tracking these branches personally, but I'd love if there were some blog posts
> > So what is the maser plan?
> >
> > Rob, are you planing to to some sort of release on your own?
>
> Rob took over maintainership while Avery isn't able to dedicate enough
> time to maintaining the project (no hard feelings, Avery, really), so
> for now the tmp/pu/master and tmp/pending/meta branches are where the
> project is living.
> I'm also trying to give Rob a hand when I can so that he's not alone in
> this.
or other describing in more human terms what these ongoing efforts were focused upon. If
they're natual continuations with no major innovations, that's cool, no posting necessary,
but if there's innovative forward-looking work being done it'd be great to have something to
discuss/reference/cite/work upon. What's happening, bup?
Reply all
Reply to author
Forward
0 new messages